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I  INTRODUCTION 


A,       SCOPE  AND  METHODOLOGY 

•  This  brief  is  part  of  INPUT'S  Customer  Service  Program  -  Europe.  The 
subject,  software  support,  was  selected  by  clients  as  a  topic  of  interest. 

•  The  report  covers  current  characteristics  and  trends  relating  to  software 
support,  including: 

Definitions  of  software  support  as  seen  by  various  respondents. 

Organisational  issues  involving  software  support. 

Strategic  considerations. 

Terms  and  conditions. 

•  Research  for  the  report  was  derived  from  four  different  INPUT  studies  in  the 
U.S.  and  Europe. 

•  This  report  focuses  on  the  issue  of  packaged  software  maintenance  in  the 
commercial  environment. 
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B.       SOFTWARE  PRODUCTS  DEFINITIONS 


•        There  are  several  subcategories  of  software  products: 

Application  Products  are  software  products  that  perform  processing  to 
serve  user  functions.  They  consist  of: 

Cross-Industry  products,  in  nnultiple-user  industry  sectors. 
Examples  are  payroll,  inventory  control,  and  financial  planning. 

Industry-Specialised  products,  in  a  specific  industry  sector  such 
as  banking  and  finance,  transportation,  or  discrete  manufactur- 
ing. Examples  are  demand  deposit  accounting  and  airline 
scheduling. 

Systems  Products  are  software  products  that  enable  the  compu- 
ter/communications system  to  perform  basic  functions.  They  consist 
of: 

Systems  operations  products,  which  function  during  applications 
program  execution  to  manage  the  computer  systems  resource. 
Examples  include  operating  systems,  DBMS,  communication 
monitors,  emulators,  and  spoolers. 

System  utilisation  products,  used  by  operations  personnel  to 
utilise  the  computer  system  more  effectively.  Examples  include 
performance  measurement,  job  accounting,  computer  operations 
scheduling,  and  utilities. 
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11        SOFTWARE  SUPPORT  CHARACTERISTICS  AND  TRENDS 


A.       WHAT  IS  SOFTWARE  SUPPORT? 

•  Software  support  does  not  have  a  commonly  accepted  definition  in  either  the 
user  or  vendor  community. 

Information  systems  departments  have  elastic  definitions  of  support 
when  maintaining  their  own  in-house-developed  software:  support 
covers  functions  ranging  from  fixing  minor  bugs  to  system  rewrites 
encompassing  many  man-years  of  effort. 

This  confusion  carries  over  into  vendor  activites.  It  is  at  least  partly 
influenced  by  the  lack  of  clarity  of  IS  departments'  expectations. 

•  Virtually  all  vendors  agree  that  fixing  software  errors  is  included  in  software 
support,  as  shown  in  Exhibit  II- 1.  It  is  interesting  that  a  few  software  vendors 
do  not  see  even  this  as  part  of  their  responsibilities. 

Most  vendors  also  see  improving,  adding,  and  extending  features  as  part 
of  software  maintenance. 

Software  vendors  are  much  less  likely  than  hardware  vendors  to  include 
training  and  consulting  as  part  of  support. 


-  3  - 
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EXHIBIT  II  I 


FUNCTIONS  INCLUDED  IN  VENDOR 
SOFTWARE  SUPPORT 
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INCLUDING  FUNCTION  IN  SUPPORT 


Fix  Errors 


Improve 
Features 


Add 
Features 


Extend 
Features 


Training 


Consulting 

Conversion 
(Hardware) 

Conversion 
(Operating 
Systems) 

Add  Interface 


92 


74 


44 


1 


22 


40 


1 


37 


20 


33 


71 


vg^"^^  80 


66 


80 


20 


40 


60 


80 


100°o 


I    i  =  Software  Company         |||||  =  Hardware  Company 


-4  - 

©1984  by  INPUT.  Reproduction  Prohibited. 


SOURCE:  INPUT  Survey 
(U.S.  Data) 


INPUT 

FPS3  FEBW 


Supplying  conversion  and  interface  assistance  is  seen  by  only  a  minority 
of  vendors  as  being  part  of  maintenance. 

Generally,  software  vendors  include  fewer  activities  in  support  than 
hardware  vendors,  except  for  conversions. 

Hardware  vendors  take  a  more  inclusive  view  of  support  because 
they  are  used  to  taking  a  more  comprehensive  view  of  cus- 
tomers' needs;  in  addition,  a  bundled  services  attitude  in  many 
cases  has  survived  unbundling. 

The  exception  for  conversions  points  up  the  different  roles  of 
hardware  and  software  companies.  Hardware  companies  will 
only  consider  conversions  within  their  own  hardware  line,  while 
software  companies  will  make  any  conversion  that  is  economic- 
ally attractive. 

Hardware  vendors  have  not  changed  their  definition  of  support  in  the  past 
three  years.  However,  30%  of  the  software  vendors  reported  doing  so  to 
adapt  to  new  markets  and  product  areas. 

Both  hardware  vendors  (60%)  and  software  vendors  (44%)  expect  to  be  making 
changes  in  the  activities  included  in  software  support.  Both  types  of  vendor 
will  try  to  reduce  the  extent  of  services  and  activities  included  in  support,  as 
part  of  their  efforts  to  reduce  the  resources  and  costs  of  software  support. 

It  is  noteworthy  that  while  fewer  than  half  the  vendors  view  training  and 
consulting  as  activities  normally  part  of  software  support,  60%  of  vendors  see 
dealing  with  user  misuse  or  lack  of  understanding  as  the  key  support  activity, 
as  shown  in  Exhibit  11-2. 

Error  correction  accounts  for  only  13%  of  activities.  (Note:  this  is 
within  the  10-20%  range  commonly  reported  for  in-house  support.) 
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EXHIBIT  II-2 


FREQUENCY  OF  SUPPORT  ACTIVITIES 


SOURCE:  INPUT  Survey  (U.S.  Data) 
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Technology  issues  (e.g.,  conversions,  upgrades,  or  improved  efficiency) 
account  for  less  than  one-fifth  of  activities. 

•  There  is  consequently  a  built-in  tension  between  what  vendors  see  as  software 
support  and  the  actual  demands  on  the  software  support  area. 

B,       ORGANISATIONAL  ISSUES 

I .       THE  CUSTOMER  SERVICE  FUNCTION 

•  In  virtually  all  companies  the  software  support  staff  is  ultimately  attached  to 
the  marketing  organisation. 

The  typical  hardware  company  organises  its  software  field  support 
organisation  as  shown  in  Exhibit  11-3.  Some  companies,  such  as  Honey- 
well, have  transferred  software  maintenance  responsibilities  (i.e.,  the 
hardware  maintenance  organisation)  to  field  engineering. 

A  number  of  other  hardware  companies  have  been  debating  the  value  of 
a  similar  transfer. 

INPUT'S  observation  is  that  such  transfers  are  neutroL  There 
are  advantages  and  disadvantages  in  having  the  software  support 
in  marketing  (which  in  effect  means  that  it  is  semi-independent) 
as  well  as  in  having  it  in  field  engineering.  Exhibit  11-4  shows 
some  of  the  pros  and  cons. 

The  value  of  such  a  transfer  will  depend  largely  on  the  status  of 
a  company's  marketing  and  field  engineering  organisations  at  a 
particular  time,  and  the  attitudes  of  key  personnel. 
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EXHIBIT  II-3 


SOFTWARE  FIELD  SUPPORT  ORGANIZATION 
IN  A  TYPICAL  HARDWARE  COMPANY 
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EXHIBIT  11-4 


ORGANIZATIONAL  LOCATION  OF 
SOFTWARE  SUPPORT  CUSTOMER  SERVICE  FUNCTIONS 


Advantages 

MARKETING 

FIELD  SERVICE 

Maintenance  is  integrated  with 
pre-  &  post-sales  support 

Maintenance  activities  can 
directly  support  sales  efforts 

Marketing  can  understand 
customer  product  needs  better 

All  maintenance  activities  are 
CO- located 

Staff  can  be  cross-trained 

Hardware  maintenance  staff 
can  be  retrained  for  software 

Disadvantages 

Marketing  is  not  technically 
oriented 

Potential  conflict  between  sales 
support  and  maintenance 

Marketing  management  may 
emphasise  sales  activities 

Hardware  and  software 
technical  issues  is  much 
different 

Interdepartmental  cooperation 
needed  to  sales  support 

Hardware  retraining  is  difficult 
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It  is  important  to  keep  in  mind  that  in  certain  critical  respects  soft- 
ware support  does  not  fit  well  in  either  marketing  or  field  engineering 
(at  least  as  it  is  presently  constituted). 

Software  in  general  is  unlike  hardware. 

Software  support  will  always  have  ties  to  the  software  develop- 
ment function. 

People  in  software  have  different  personal  characteristics  and 
attitudes  from  people  in  marketing  and  field  engineering. 

•  Regardless  of  the  organisational  sponsorship,  communication  between  the 
customer  and  the  central  maintenance  group  will  follow  the  process  shown  in 
Exhibit  11-5. 

The  customer  support  representatives  are  not  necessarily  technically 
trained  in  the  internals  of  the  product,  but  have  an  excellent  hands-on 
knowledge  of  the  product  from  the  user's  perspective. 

If  the  vendor  has  a  large  enough  customer  base  and  resources, 
the  representatives  will  specialise  by  product. 

The  staff  can  also  provide  sales  and  installation  support. 

Personality  is  more  important  than  intellectual  skills. 

The  software  support  technicians  are  middlemen. 

They  back  up  the  customer  support  representatives  on  narrow  or 
technical  issues. 
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They  must  specialise  by  product. 


They  are  filters  to  the  central  maintenance  group. 

The  maintenance  group  is  made  up  of  true  software  technicians  (pro- 
grammers and  analysts). 

They  must  keep  up  some  contact  with  the  field  staff  (and  even 
customer)  so  that  they  do  not  become  divorced  from  the  real 
world. 

They,  in  turn,  must  interact  with  the  new  product  development 
group.  This  relationship  is  the  subject  of  the  next  section. 

THE  RELATION  OF  THE  DEVELOPMENT  AND  MAINTENANCE  FUNCTIONS 

The  role  of  the  software  support  staff  varies  from  company  to  company. 

Generally  speaking,  the  support  staff  is  highly  (usually,  solely)  involved 
with  customer  contact,  as  well  as  error  determination  and  correction. 
There  is  less  involvement  in  the  design  coding  and  documentation  of 
software  revisions,  as  shown  in  Exhibit  11-6. 

The  software  development  group  mirrors  the  support  group's  involve- 
ment, as  shown  in  Exhibit  11-7. 

Development  groups  in  hardware  companies  tend  to  be  more  involved 
than  those  in  software  companies,  as  shown  in  Exhibit  11-8. 

Respondents  express  satisfaction  with  present  arrangements  and  plan 
few  changes. 
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EXHIBIT  11-6 


SOFTWARE  SUPPORT  STAFF  FUNCTIONAL  INVOLVEMENT 
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EXHIBIT  II-7 


SOFTWARE  DEVELOPMENT  GROUP  FUNCTIONAL  INVOLVEMENT 


100% 


90 


80 


70 


C/l 

0) 

c  60 

Q. 
E 
o 

^  50 


§  40 

0) 
Q. 


30 


20 


10 


—  17 


90 


30 


17 


50 


10 


1 


Customer  Contact 


Error 


Error       Enhancement      Coding  Documentation 
Telephone        Personal    Determination  Correction         Design  Revisions  Revision 


=  Software  Companies 


=  Hardware  Companies 


*  Quality  Control  also  involved  in  17%  of  companies 
**  Documentation  Group  also  involved  in  21%  of  companies 


SOURCE:  INPUT  Survey 
(U.S.  Data) 


-  14  - 

'1984  by  INPUT.  Reproduction  Prohibited. 


INPUT 

FPS3FEBW 


EXHIBIT  II-8 

EXTENT  OF  INVOLVEMENT  OF 
DEVELOPMENT  GROUP  IN  SUPPORT 


SOFTWARE  VENDORS 


HARDWARE  VENDORS 


SOURCE:  INPUT  Survey 
(U.S.  Data) 
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There  are  three  basic  models  for  organising  the  central  software  maintenance 
function: 

These  approaches  can  be  labeled  as: 
Coordinated. 
Integrated. 
Independent. 

In  the  coordinated  approach  software  support  and  development  are 
separate  entities,  but  they  report  to  the  same  product  software 
manager. 

The  integrated  approach  is  similar,  except  that  the  developer  and 
maintainer  roles  are  not  distinct.  There  is  much  trading  of  responsi- 
bilities. No  one  is  stuck  doing  support. 

The  independent  approach  separates  developers  and  supporters. 
Separate  support  career  paths  and  specialisations  can  be  developed. 
This  is  not  practical  if  the  entire  staff  for  a  software  product  (or 
product  group)  is  small  (i.e.,  under  25). 

Exhibit  11-9  shows  the  three  approaches  graphically. 

Each  organisational  option  has  different  effects  on  the  turnover,  morale, 
skills,  and  feasible  project  size  of  the  central  software  maintenance  organisa- 
tion. Exhibit  11-10  summarises  these  effects. 

The  independent  organisation  is  the  most  conducive  to  effective  main- 
tenance activities.  However,  skills  are  needed  to  coordinate  the  range 
of  software  activities  for  a  given  product.  The  development  group  will 
usually  oppose  this  approach. 
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EXHIBIT  11-9 


ORGANIZATIONAL  ALTERNATIVES  FOR 
CENTRAL  SOFTWARE  SUPPORT  FUNCTION 
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EXHIBIT  11-10 


EFFECTS  OF  SOFTWARE  SUPPORT  ORGANIZATION  OPTIONS 


MAINTENANCE  PHYSICALLY  AND 
ORGANIZATIONALLY  DISTINCT 

Yes 

No 
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(Coordinated) 

Low  Turnover 

High  Turnover 

ORGANIZATION 
TENANCE  ONLY 
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High  Morale 

High  Skills  Developed 

Large  Project 
Size  Feasible 

Low  Morale 

Medium  Skills  Developed 

Large  Project 
Size  Feasible 

MAINTENANCE  < 
PERFORMS  MAIN 

No 

N/A 

( I ntegrated) 

Medium  Turnover 

Medium  Morale 

Medium  Skills 

Medium  Project 
Size  Feasible 
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The  integrated  approach  is  well-suited  to  small  software  groups.  The 
problem  is  that  no  one  wants  to  do  support,  and  the  integrated  ap- 
proach often  degenerates  into  the  coordinated  approach. 


C.       SOFTWARE  SUPPORT  STRATEGIES 


I.       STRENGTHS  AND  WEAKNESSES 

•  In  developing  a  strategy  for  approaching  software  support,  the  first  questions 
to  ask  are:  "What  kind  of  company  am  I?"  then,  "Will  I  be  the  same  company 
in  five  years?" 

The  obvious  place  to  start  is  with  the  differences  between  hardware 
and  software  companies.  Some  of  the  advantages  and  disadvantages  of 
each  are  summarised  in  Exhibit  ll-l  I. 

Many  of  the  strengths  and  weaknesses  of  software  companies 
are  due  to  their  relatively  small  size.  ' 

Hardware  companies,  especially  the  mainframe  companies,  are 
more  ponderous  and  structured  organisations.  This  is  not  always 
a  disadvantage  for  a  support  function.  Customers  expect 
support  to  be  uniform  and  by-the-numbers.  There  is  little  room 
for  inspiration  in  a  support  environment. 

Exhibit  ll-l  I  should  not  be  taken  as  a  prescription  for  every  company. 
Each  company  is  in  a  unique  situation.  Ideally,  each  company  will 
make  its  own  list  of  strengths  and  weaknesses  and  look  for  ways  to 
build  on  strengths  and  minimise  weaknesses. 
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EXHIBIT  11-11 
SOFTWARE  SUPPORT  STRENGTHS: 
HARDWARE  COMPANIES  AND  INDEPENDENT  SOFTWARE  COMPANIES 
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Advantages 

High  profile  in  area  of 
specialization 

Large  resource  base  (dollars, 
people) 

Deep  knowledge  of  products  and 
market  in  area  of  specialization 

Integrated,  comprehensive 
software  products 

Quick  reactions  to  market 

Relatively  easy  for  new  entrants 
to  produce  products 

Attractive  to  entrepreneurial/ 
risk-taking  staff  attempting 
breakthrough  products 

Good  geographic  support  for 
marketing  and  support 

Sole  source  for  some  systems 
software 

Much  closer  integration  of 
hardware  and  software 

Disadvantages 

Limited  resource  base  (dollars, 
people) 

Resources  possibly  spread  too 
thin 

Product  line  usually  limited  ^ 

Difficult  to  obtain  satisfactory 
marketing  and  support 
geographic  coverage 

Software  products  possibly 
obsolescent,  inadequate,  or 
nonexistent 

Reaction  time  may  be  slow 

Relatively  easy  for  new  entrants 
to  produce  products 

Must  react  to  hardware  changes 

Risk  taking  may  not  be  welcomed 

Software  traditionally  only 
offered  for  own  hardware 
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SUPPORTING  INDEPENDENTLY  DEVELOPED  SOFTWARE 


In  the  past,  vendors  tended  to  develop  their  own  software.  There  was  then 
little  question,  or  option,  of  who  would  support  the  software. 

This  situation  is  now  changing  as  more  companies  are  adding  specific  software 
products  from  outside  suppliers  to  their  own  line  of  products. 

One  alternative,  followed  by  many  minicomputer  and  small  system 
vendors,  is  not  to  actually  acquire  the  software,  but  to  keep  at  arm's 
length  from  the  vendor. 

At  the  most,  the  hardware  vendors  examines  the  software  and 
recommends  its  use. 

At  the  least,  the  hardware  vendor  merely  maintains  lists  of 
software  products  but  makes  no  recommendations  of  one  over 
another. 

Either  way,  the  hardware  vendor  has  little  control  over  the 
product's  evolution,  its  quality,  or  even  its  existence. 

The  alternative,  followed  by  such  diverse  companies  as  IBM  and  Culli- 
nane,  is  to  buy  up  rights  to  a  product.  Where  product  presence  is 
desirable,  this  gives  a  vendor  a  proprietary  product  and  complete 
control  over  it. 

The  question  then  becomes:  will  the  buying  or  selling  company  support  the 
software? 

The  main  reason  for  going  outside  in  the  first  place  is  to  lower  the 
investment  in  time  and  resources  to  develop  a  software  product. 
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Contracting  with  the  seller  to  continue  supplying  central  support 
functions  would  lower  initial  investment. 

It  may  be  possible  as  part  of  the  acquisition  to  take  on  part  of  the 
seller's  technical  and  support  staff.  This  is  a  desirable  alternative,  if 
feasible.  However,  many  people  will  not  want  to  leave  their  company 
or  will  not  last  long  in  a  new,  usually  much  larger  company. 

Exhibit  11-12  summarises  the  pros  and  cons  of  having  the  buyer  or  seller 
support  third-party-developed  software. 

NEW  VERSUS  ENHANCED  SOFTWARE  PRODUCTS 

One  of  the  barriers  to  making  software  support  into  a  functioning  P&L  center 
is  that  some  of  the  most  attractive  enhancements  to  existing  software  can 
just  as  easily  be  packaged  as  new  products.  If  this  is  done,  the  benefits  do  not 
accrue  to  the  software  support  organisation. 

Many  software  planners  freely  admit  that  their  firms  do  not  have  hard  and 
fast  rules  for  deciding  when  a  bundle  of  capabilities  is  a  new  product  (as 
opposed  to  an  enhancement),  or  what  constitutes  a  major  as  opposed  to  a 
minor  enhancement.  Exhibit  11-13  shows  the  relationship,  and  overlap,  be- 
tween new  product  development  and  support  enhancements. 

Existing  customers,  of  course,  want  all  possible  product  additions  to  be  con- 
sidered enhancements  and  included  as  standard  revisions  covered  by  their 
maintenance  contracts.  Older  customers  (and  some  old-time  vendor  per- 
sonnel) identify  with  the  bundled  software  era  when  everything  was  free. 

In  reality,  customers  have  little  or  no  contracted  protection  from 
vendors  announcing  an  improved  software  product,  and  charge  current 
customers  a  significant  proportion  of  list  price,  if  not  the  full  list 
price. 
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EXHIBIT  11-12 


SUPPORTING  INDEPENDENTLY  DEVELOPED  SOFTWARE: 

BUYER  OR  SELLER? 


ADVANTAGES  TO 
BUYER  SUPPORTING 

ADVANTAGES  TO 
SELLER  SUPPORTING 

•  More  direct  quality  control 

•  Easier  maintenance  of  docu- 
mentation and  other  standards 

•  Possible  addition  of  key  seller 
staff 

•  Difficulty  in  motivating  staff 
for  maintenance 

•  Easier  field /central-staff 
coordination 

•  Lower  initial  investment  in  re- 
sources and  management  time 

•  Conserve  scarce  in-house 
staff 

©  Greater  expertise  of  seller's 
staff 

•  Reluctance  of  seller's  staff 
to  join/stay  with  buyer 
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EXHIBIT  11-13 


DEGREE  OF  INVOLVEMENT  OF  NEW  PRODUCT 
DEVELOPMENT  AND  SUPPORT 


_.  .  ,  .  Extending  a^-j-  Adding 

F.x.ng  ^  '";P»"^.^'"g  •  Current  •  Adding  ^  Features  and 
Errors  Usability  Features  Interfaces  Functions 
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The  only  barrier  to  this  (but  it  is  a  strong  one)  is  the  long-term  damage 
it  will  do  to  the  vendor's  standing  in  the  marketplace.  Some  vendors 
have  damaged  their  reputations  in  this  way,  usually  because  of  serious 
financial  pressures. 

Some  vendors  adopt  a  middle  path,  announcing  a  higher-priced,  improved 
product,  while  including  many  of  the  new  features  as  maintenance  revisions  to 
current  products. 

This  approach  must  be  well  thought  out  from  a  marketing  standpoint  so 
that  satisfying  current  customers  does  not  undermine  future  sales. 

There  is  a  long-term  technical  burden  in  maintaining  two  or  more 
similar,  but  not  identical,  products. 

For  this  reason  many  vendors  "bite  the  bullet"  and  make  it  financially  advan- 
tageous to  upgrade  to  new  products,  especially  when  the  old  product,  at  a 
technical  dead  end,  will  not  attract  many  new  sales  in  any  event. 

Negative  incentives  can  also  be  applied  by  announcing  that  support  of 
the  old  product  will  be  stopped  soon  (generally  in  less  than  a  year). 

This  will  get  the  new  product  off  to  a  rousing  start  by  giving  it  an 
instant  track  record. 

OPPORTUNITIES  IN  SOFTWARE  SUPPORT 

Not  all  software  packages  are  created  equal  from  a  software  support  stand- 
point. 

Few  customers  will  want  to  go  bare  on  operating  system  maintenance, 
even  if  they  have  the  chance. 
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On  the  other  hand,  nnany  purchasers  of  large,  industry-specialised 
packages  buy  the  package,  intending  to  modify  it  extensively.  For 
them,  support  is  just  a  tax  on  the  purchase  price. 

A  buyer  of  small,  stable  packages  that  have  been  in  existence  for  some 
time  will  rarely  feel  the  need  for  extensive  support. 

Support  is  perceived  as  highly  valuable  in  large,  complex  packages  that 
the  customer  has  no  intention  of  modifying.  DBMS  is  a  good  example 
of  this  type  of  product. 

These  relationships  can  be  graphically  illustrated,  as  shown  in  Exhibit 
11-14. 

This  is  not  to  say  that  vendors  should  ignore  the  low-need  areas.  These  can  in 
fact  be  the  most  profitable.  Two  approaches  can  be  made: 

Tax:  Given  the  relative  price-insensitivity  to  software,  if  a  customer 
sees  a  need  for  a  package  at  $X,  then  the  customer  will  usually  not 
balk  at  an  additional  $.IX  per  year.  If  the  vendor  has  an  attractive 
product,  then  there  should  be  a  mandatory  support  requirement,  at 
least  for  several  years. 

Insurance  Policy:  The  other  approach,  useful  for  small,  stable  pack- 
ages, is  to  have  a  nominal  support  price,  covering  error  fixes  only.  At 
the  right  price,  customers  will  buy  the  insurance  for  at  least  several 
years. 

Vendors  should  keep  in  mind  that  in  general  support  has  not  been  tracked  or 
controlled  very  precisely  in  many  data  processing  budgets. 
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EXHIBIT  11-14 
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In  some  companies,  operations  software  (and  its  support)  is  included  in 
hardware  budgets,  a  remnant  of  bundled  hardware  days. 

In  other  companies,  hardware  and  software  maintenance  budgets  are 
combined. 

In  still  others,  specific  application  software  and  maintenance  expenses 
are  charged  to  a  particular  application  system. 

In  many  companies,  these  different  classifications  are  being  used 
simultaneously. 

There  have  been  some  attempts  to  tighten  up  as  a  result  of  the  current 
recession;  however,  software  maintenance  is  too  scattered  and  misun- 
derstood for  cost  cutting  to  have  much  effect. 

STRATEGIC  CONSIDERATIONS 

Software  support  can  be  an  important  part  of  a  company's  business  strategy. 
Software  support  is  in  some  ways  the  last  frontier  for  many  companies. 

Hardware's  price/performance  and  reliability  are  improving  rapidly. 
Unfortunately  for  established  vendors,  these  same  factors  are  turning 
many  hardware  products  into  a  commodity  market. 

Hardware  maintenance  has  been  most  resistant  to  these  tenden- 
cies, but  even  here  third-party  maintainers  have  gotten  a  foot- 
hold. 

Over  the  longer  term,  rapidly  falling  prices  and  increasing 
reliability  will  reduce  hardware  maintenance  opportunities. 


-28- 

©1984  by  INPUT.  Reproduction  Prohibited. 


INPUT 


Software  in  general  is  a  messy  area.  It  is  expensive  to  produce  and 
often  only  marginally  meets  customer  needs.  Software  productivity 
has  lagged  far  behind  hardware  performance.  New  software  products, 
especially  for  smaller  systems,  are  easy  to  produce  in  the  well-known 
garage. 

This  places  pressure  on  established  vendors. 

Outsiders  cannot,  however,  feasibly  offer  add-ons  or  mainte- 
nance to  existing  software  products.  Consequently,  it  is  the 
most  protected  area  for  established  vendors. 

Exhibit  11-15  summarises  these  relationships  and  trends. 

•  The  conclusion  is  that  software  and  especially  software  maintenance  are 
tough  areas  for  developing  satisfactory  products  economically.  Vendors  who 
can  make  even  marginal  breakthroughs  should  be  able  to  reap  large  rewards. 

P.       TRENDS  AND  DEVELOPMENT 

•  Many  vendors,  like  IBM,  are  assigning  software  distribution  and  some  mainte- 
nance to  their  field  service  divisions.  This  is  done  to  provide  a  central  source 
that  the  customer  can  go  to  for  total  service  from  one  vendor. 

•  Typically,  it  is  not  the  engineer  in  the  field,  but  a  centralised  hotline  service 
center  that  provides  maintenance  and  distribution  support.  For  example, 
Honeywell's  Remote  Support  Update  Facility  provides  maintenance  service  to 
users  for  applications  and  systems  software. 

•  Users  of  small  systems  are  undecided  as  to  what  the  role  of  the  FE  should  be 
in  terms  of  software  support.    On  one  hand  users  rate  communications  with 
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EXHIBIT  11-15 


STRATEGIC  FACTORS  FOR 
HARDWARE  AND  SOFTWARE  PRODUCTS 


COST  TO 
PROVIDE 

CUSTOMER 
NEEDS 
SATISFACTION 

RELIABILITY 

RESISTANCE 

TO  NEW 
COMPETITORS 

Hardware  Products 

+  + 

+  + 

+ 

Hardware  Enhancements 

+  + 

+  + 

+ 

Hardware  Support 

+ 

0 

+ 

+ 

Software  Products 

0 

Software  Enhancements 

0 

+  + 

Software  Support 

+  + 

Key:  +  +  =  Very  Favorable 
+  =  Favorable 
0  =  Neutral 
—  =  Unfavorable 
 =  Very  Unfavorable 
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software  engineers  significantly  lower  than  they  do  connmunications  with 
hardware  engineers.  This  suggests  that  the  personal  interaction  between  the 
hardware  FE  and  the  user  could  be  used  to  improve  software  support.  On  the 
other  hand,  users  definitely  want  to  restrict  the  FE's  function  to  only  hard- 
ware support.  For  example,  almost  60%  of  small-system  users  interviewed  by 
INPUT  opposed  FEs  that  sell  software. 

The  need  for  centralised  software  support  and  personal  interaction  with  the 
user  has  caused  a  majority  of  small-system  vendors  to  begin  integration  of 
hardware  and  software  support  functions.  Exhibit  11-16  demonstrates  the 
degree  to  which  integration  has  been  completed. 

Exhibit  11-16  shows  that  a  slightly  higher  percentage  of  vendors  are  integrat- 
ing systems  software  into  hardware  functions,  than  they  are  applications 
software  support  into  the  hardware  function.  This  is  caused  by  two  factors: 

Applications  software,  even  when  licensed  by  the  small-system  vendor, 
is  often  written  by  a  third  party.  The  third  party  usually  maintains  its 
own  software  support  group. 

Conversely,  systems  software  is  usually  the  responsibility  of  the  vendor 
and  is  instrumental  in  the  overall  functioning  of  the  system. 

One  factor  that  vendors  report  may  limit  the  integration  of  hardware  and 
software  maintenance  is  the  variability  of  software.  While  hardware  is  gener- 
ally quite  standard,  customisation  of  software  is  common  and  limits  the 
degree  to  which  it  can  be  maintained  by  standard  maintenance  procedures. 

Despite  diversity  in  software,  it  is  likely  that  vendors  will  move  toward  in- 
creased integration.  Vendors  reported  that  application  software  integration 
will  lag  behind  system  software  integration,  but  that  overall  integration  will 
grow  substantially  in  the  next  three  to  five  years. 
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EXHIBIT  11-16 


SMALL-SYSTEM  INTEGRATION  OF  SOFTWARE 
SUPPORT  INTO  HARDWARE  SUPPORT  FUNCTION 


DEGREE  OF 
INTEGRATION 

INTEGRATION  OF  LARGE- 

PERCENT  OF 

(percent) 

SYSTEM  SOFTWARE 
SUPPORT  ACTIVITY 

VENDORS 
IMPLEMENTING 

1983 

1  985 

Systems  Software 

60% 

46% 

68% 

Applications  Software 

53 

27 

47 

SOURCE:  INPUT  Survey  (U.S.  Data) 
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While  the  1980s  will  continue  the  trend  toward  reduced  hardware  costs  or 
increased  processing  capacity  for  the  same  cost,  this  does  not  necessarily 
mean  that  full  computer  systems  will  be  less  expensive  in  the  1980s.  Total 
software  costs  are  increasing,  resulting  from  increased  sophistication  as  well 
as  from  rapidly  escalating  labor  costs.  However,  the  impact  of  increasing 
software  costs,  like  other  facets  of  computer  technology,  may  be  reduced  by 
innovative  ideas  and  advanced  technology. 

One  approach  is  to  incorporate  software  into  computer  hardware.  IBM  is 
currently  planning  this  approach  through  the  introduction  of  an  omnibox  in  the 
mid-1980s.  This  unit  would  be  an  entire  system,  including  the  central  com- 
puter and  peripherals,  packaged  in  a  box  two  cubic  meters  in  size.  This  unit 
would  have  many  software  functions  preprogrammed  as  firmware.  While  such 
systems  may  have  limited  versatility,  the  special-purpose  software-oriented 
mainframe  computer  may  also  be  a  trend  in  the  1980s. 

Past  practice  has  been  to  design  a  general  or  multipurpose  central  processor 
and  then  program  the  specific  job  application  in  order  to  achieve  the  desired 
system.  Future  mainframes  may  very  well  be  either  microprocessors  with 
incorporated  hardware  to  perform  a  prespecified  task  or  a  combination  of 
several  microprocessors  designed  to  encompass  all  of  a  firm's  application 
processing  needs.  This  may  become  feasible  because  a  tradeoff  exists  be- 
tween decreasing  hardware  costs  and  increasing  software  costs,  especially  for 
scientifically  oriented  applications. 

Under  any  circumstances,  the  servicing  and  support  of  software  in  large 
mainframes  will  become  an  increasingly  important  function.  In  today's 
environment,  the  field  engineer  is  primarily  hardware  oriented.  Software 
support  is  provided  by  technical  assistance  centers.  Increasingly,  service 
engineers  must  be  provided  with  direct  access  to  this  specialised  software 
knowledge  while  at  the  job  site.  One  approach  is  to  use  handheld/portable 
computers  as  a  mechanism  for  software  diagnostics  and  direct  access  to 
software  specialists. 
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Ill       THE  STATE  OF  SOFTWARE  SUPPORT  IN  EUROPE 

A.       USER  RATINGS  OF  SOFTWARE  SUPPORT  BY  VENDOR 

•        Exhibit  ili-i  indicates  that  users'  perceptions  of  the  software  support  they 
receive  from  vendors  is  good  to  excellent. 


Vendors  receiving  highest  marks  are: 
Amdahl. 
DEC. 
Ericsson. 

Honeywell  (Benelux). 

IBM. 

Norsk. 

Vendors  receiving  lower  marks  are: 
Honeywell  (Germany). 
ICL. 
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EXHIBIT  lll-l 


USER  RATINGS  OF  SOFTWARE  SUPPORT 


UNITED 
KINGDOM 

GERMANY 

FRANCE 

BENELUX 

SCANDINAVIA 

ITALY 

Amdahl 

Excellent 

- 

- 

- 

- 

- 

Burroughs 

Good 

- 

Good 

Good 

Good 

- 

DEC 

Excellent 

- 

Good 

Very  Good 

- 

Good 

Ericsson 

- 

- 

- 

- 

Excellent 

- 

Hewlett- 
Packa rd 

Good 

- 

Very  Good 

- 

- 

Good 

Honeywell 

Good 

Adequate 

Good 

Very  Good 

Excellent 

Good 

IBM 

Good 

Good 

Good 

Good 

Excellent 

Good 

ICL 

Good 

Adequate 

Good 

Good 

NCR 

Very  Good 

Adequate 

Norsk 

Excellent 

Prime 

Good 

Siemens 

Good 

Adequate 

Sperry 

Adequate 

Adequate 

Very  Good 

Good 

-  =  No  Data  SOURCE:  INPUT  Survey 
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NCR. 

Siemens. 

Sperry. 

B.  QUALITY  OF  SOFTWARE  SUPPORT 

•  Overall  quality  of  software  support  is  good  to  very  good  as  shown  in  Exhibit 
III-2. 

The  U.K.,  German,  and  French  users  rate  software  support  highly  in  all 
three  categories  including  large,  small,  and  all  systems.  "All"  includes 
large  and  small  as  well  as  intelligent  terminals,  word  processors,  etc. 

Representative  ratings  are  also  shown  for  Benelux,  Scandinavia,  and 
Italy. 

C.  TRENDS  IN  SOFTWARE  SUPPORT  IMPORTANCE  AS  SEEN  BY  USERS 

•  Software  support  is  certainly  important  in  the  eyes  of  the  user.  INPUT  has 
measured  this  for  the  past  three  years  and  the  results  are  shown  in  Exhibit 
III-3. 

In  the  U.K.,  software  support  has  been  and  remains  extremely  impor- 
tant to  users. 
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EXHIBIT  III-2 


SOFTWARE  SUPPORT  QUALITY  RATED  BY  USERS 


LARGE  SYSTEMS 

SMALL  SYSTEMS 

ALL  SYSTEMS 

United 
Kingdom 

Very  Good 

Very  Good 

Very  Good 

Germany 

Very  Good 

Very  Good 

Very  Good 

France 

Very  Good 

Very  Good 

Very  Good 

Benelux 

Good 

Good 

Very  Good 

Scandinavia 

Good 

Good 

Good 

Italy 

Good 

Very  Good 

Good 

SOURCE:  INPUT  Survey 
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EXHIBIT  III-3 


TRENDS  IN  SOFTWARE  SUPPORT  IMPORTANCE 
AS  SEEN  BY  USERS 


1983 

1982 

1981 

United 
Kingdom 

Extremely  Important 

Extremely  Important 

Extremely  Important 

Germany 

Extremely  Important 

Critical 

Important 

France 

Critical 

Extremely  Important 

Important 

Benelux 

Extremely  Important 

Extremely  Important 

Extremely  Important 

Scandinavia 

Extremely  Important 

Important 

Important 

Italy 

Extremely  Important 

Extremely  Important 

1  mportant 

SOURCE:  INPUT  Survey 
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In  Germany,  software  support  became  critical  to  users  in  1982  but 
lately  it  reflects  users'  perceptions  of  the  apparent  lack  of  confidence 
in  software  support  resources. 

•  The  importance  of  software  support  in  Benelux,  Scandinavia,  and  Italy  has 
risen  currently,  as  users  there  become  worried  about  resources. 

D.       SOFTWARE  REPAIR  TIME 

•  Exhibit  ill-4  indicates  a  wide  variation  in  perceived  software  repair  times  in 
terms  of  what  users  think  they  now  get,  the  ideal  target,  and  the  acceptable 

maximum, 

•  Software  repair  times,  as  perceived  by  users,  exceed  customers'  limits  in 
France,  Scandinavia,  and  Italy  -  indicating  that  more  software  support  skills 
are  required. 

•  In  the  U.K.,  Germany,  and  Benelux,  perceived  repair  times  for  software  are 
less  than  the  limits  established  by  users.  This  indicates  that  resources  are 
adequate. 


E.       BETTER  SOFTWARE  SERVICE  REQUIRED  FROM  USERS 

•        While  European  users  seem  very  satisfied  with  the  quality  of  software  support, 

improvements  are  required  in  Benelux,  the  U.K.,  and  Itoly,  as  depicted  in 
Exhibit  111-5. 


-40  - 

©  1984  by  INPUT.  Reproduction  Prohibited. 


INPUT 


EXHIBIT  III-4 


SOFTWARE  REPAIR  TIME  (In  Hours) 


CURRENTLY 
RECEIVE 

IDEAL 

LIMIT 

II.    '  J.  -J 

United 
Kingdom 

7.  5 

II  c 

4.  b 

0  c 
0 .  0 

Germany 

3.  1 

2.  7 

7.4 

France 

13.0 

11.0 

9.0 

Benelux 

6.8 

2.3 

7.  7 

Scandinavia 

5.7 

2.  1 

4.  3 

Italy 

20.9 

2.9 

6.5 

SOURCE:  INPUT  Survey 
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EXHIBIT  III-5 


BETTER  SOFTWARE  SERVICE  REQUIRED  FROM  USERS 


DECREE  OF 

RFHI  II  RFMFNT 

r\CV^  VJ  1  rx  EllVI  C  IN  1 

United 
Kingdom 

Strong 

Germany 

Moderate 

France 

Moderate 

Benelux 

Urgent 

Scandinavia 

^  Nil 

Italy 

Strong 

SOURCE:  INPUT  Survey 
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F.       SOFTWARE  SUPPORT  PRICING 


•  There  is  a  general  underpricing  of  software  support  in  Europe,  as  shown  in 
Exhibit  The  value  of  the  underpricing  was  determined  using  figures  from 
users  representing  their  limits  versus  what  they  currently  thought  they  were 
getting. 

«  In  each  country  there  is  room  to  price  software  support  at  higher  levels,  with 
Scandinavia,  Benelux,  Germany,  and  Italy  being  prime  targets. 

G.  USER  INTEREST  IN  PROVIDING  SOFTWARE  ASSISTANCE 

•  On  the  whole,  users  are  quite  interested  in  providing  assistance  to  software 
support  vendors,  in  terms  of  helping  with  diagnosis  and  patching,  as  described 
in  Exhibit  III-7. 

•  With  the  exception  of  West  Germany,  this  willingness  on  the  part  of  users 
should  be  exploited  by  software  support  vendors. 

H.  SOFTWARE  SERVICE  PRODUCTS*  MARKET  POTENTIAL 

•  There  are  fair  to  excellent  possibilities  for  new  service  products  involving 
software  support,  as  shown  in  Exhibit  1 1 1-8. 

•  A  provision  for  guaranteed  turnaround  on  software  fixes  is  in  high  demand, 
generally,  as  are  software  consulting  services.  Software  enhancement  ser- 
vices opportunities  are  better  still. 
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EXHIBIT  111-6 


SOFTWARE  SUPPORT  PRICING  AS  SEEN  BY  USERS 


UNDERPRICING 
PERCENT 

United 
Kingdom 

3-6% 

Germany 

4-10 

France 

2-4 

Benelux 

5-11 

Scandinavia 

6-13 

Italy 

4-10 

SOURCE:  INPUT  Survey  and  Estimates 
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EXHIBIT  III-7 


USER  INTEREST  IN  PROVIDING  SOFTWARE  ASSISTANCE 


HELPING  DIAGNOSE 

HELPING  PATCH 

United 
Kingdom 

Very  Interested 

Very  Interested 

Germany 

Not  Very  Interested 

Not  Very  Interested 

France 

Very  Interested 

Very  Interested 

Benelux 

Very  Interested 

Very  Interested 

Scandinavia 

1 nterested 

I nterested 

Italy 

Very  Interested 

I nterested 

SOURCE:  INPUT  Survey 
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EXHIBIT  III-8 


SOFTWARE  SERVICE  PRODUCTS'  MARKET  POTENTIAL 


SERVICE  PRODUCTS' 
MARKET  POTENTIAL 

GUARANTEED 
TURNAROUND 
ON  SOFTWARE 

SOFTWARE 
CONSULTING 
SERVICE 

SOFTWARE 
ENHANCEMENTS 

United 
Kingdom 

Good 

Fair 

Good 

Germany 

Fair 

Fair 

Fair 

France 

Good 

Good 

Good 

Benelux 

Fair 

Fair 

Good 

Scandinavia 

Excellent 

Excellent 

Excellent 

Italy 

Very  Good 

Very  Good 

Very  Good 

SOURCE:  INPUT  Survey 
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•        The  potential  market  is  good  to  excellent  in  France,  Scandinavia,  and  Italy. 


1.       GROWTH  IN  USER  SOFTWARE  BUDGETS 


•  As  can  be  seen  in  Exhibit  III-9,  the  growth  in  software  support  is  expected  to 
rise  in  1985  to  32%  of  hardware  maintenance  budgets,  according  to  users. 

•  in  terms  of  projections  based  on  INPUT'S  1983  Field  Service  Annual  Report 
this  means  that  the  value  of  software  support  approaches  $2  billion  for  all  of 
Europe. 
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EXHIBIT  III-9 

GROWTH 

IN  SOFTWARE  SUPPORT 

USER  SOFTWARE 
SUPPORT  BUDGETS 
AS  A  PERCENT  OF 
HARDWARE  MAINTENANCE 

1983 

25% 

1984 

28 

1985 

32 
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APPENDIX: 


SOFTWARE  SUPPORT  TERMS  AND  CONDITIONS 


•  Hardware  companies  are  less  likely  to  have  separate  support  charges  where 
the  software  is  leased  or  where  use  pricing  is  used,  as  shown  in  Exhibit  A- 1. 
Otherwide,  the  profiles  are  similar. 

•  There  is,  however,  considerable  variation  in  the  approaches  used  to  set 
support  charges,  as  shown  in  Exhibit  A-2, 

•  An  annual  fee  of  10%  to  12%  of  purchase  price  is  common  for  most  software 
vendors  (67%),  as  shown  in  Exhibit  A-3.  The  fee  varies  for  other  companies. 

•  Support  typically  includes  both  fixes  and  enhancements  for  software  com- 
panies (93%);  this  is  less  common  for  hardware  companies  (50%),  as  shown  in 
Exhibit  A-3. 

The  point  at  which  an  enhancement  becomes  a  new  product  can  depend 
on:  ■) 

Size  of  product. 

Changes  in  functionality. 

•  The  minimum  support  term  is  usually  12  months  for  software  companies,  as 
shown  in  Exhibit  A-3.  This  is  only  true  for  50%  of  hardware  companies. 
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EXHIBIT  A-1 


SEPARATE  SUPPORT  CHARGES 
(Summary) 


TYPE  OF 
SOFTWARE  LICENSE 



HARDWARE 
COMPANIES 
(percent) 

SOFTWARE 
COMPANIES 
(percent) 

Lease 

33% 

90% 

Continuous  Payment 

40 

42 

Use  Pricing 

50 

80 

Paid-Up 

86 

100 

One-Time  Charge 

86 

100 

NOTE:     (1)   Percentages  against  companies  that  have  that  type  of  software  license. 
(2)   If  in  fee,  but  optional,  counted  as  separate. 

SOURCE:  INPUT  Survey  (U.S.  Data) 
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Hardware  maintenance  is  sometimes  a  prerequisite  for  obtaining  software 
support  for  hardware  companies  (30%),  as  shown  in  Exhibit  A-3. 

Most  vendors  use  most  of  the  available  methods  of  distributing  software  fixes 
to  customers,  as  shown  in  Exhibits  A-4  and  A-6. 

Software  firms  are  more  likely  than  hardware  companies  to  have  the  customer 
apply  the  fix,  as  shown  in  Exhibits  A-5  and  A-6. 

Support  for  back  levels  of  a  release  varies  from  none  to  forever,  as  shown  in 
Exhibit  A-6. 

There  are  few  response  time  promises  for  making  software  fixes,  as  shown  in 
Exhibit  A-6. 

Trouble  report  turnaround  varies,  as  shown  in  Exhibit  A-6.  Immediate  turn- 
around is  the  most  common. 

Hardware  companies  are  more  likely  to  give  a  price  discount  for  multilicense 
support  (40%)  than  software  companies  (13%),  as  shown  in  Exhibit  A-7. 
Central  support  arrangements  are  common  among  software  companies  (73%); 
they  are  less  common  among  hardware  companies  (40%). 

On-site  maintenance  pricing  ranges  from  about  $200/day  to  $850/day,  as 
shown  in  Exhibit  A-7.  The  majority  are  in  the  $500  to  $800  range. 
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EXHIBIT  A-4 


METHODS  OF  DISTRIBUTING 
SOFTWARE  FIXES  TO  CUSTOMER 
(percent) 


TYPE  OF 
NOTIFICATION 

HARDWARE 
COMPANIES 

SOFTWARE 
COMPANIES 

On-Site 

70% 

80% 

Telephone 

70 

93 

Letter 

50 

47 

Newsletter 

70 

47 

Maintenance  Release 

70 

87 

All  Users 

90 

93 

SOURCE:  INPUT  Survey  (U.S.  Data) 
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EXHIBIT  A-5 


APPLICATION  OF  SOFTWARE  FIXES 
(percent) 


FIXES 

HARDWARE 

SOFTWARE 

APPLIED  BY 

COMPANIES 

COMPANIES 

Vendor 

50% 

33% 

Customer 

60  , 

87 

SOURCE:  INPUT  Survey  (U.S.  Data) 
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